Fix various UndefinedBehaviorSanitizer warnings #315
Conversation
Co-authored-by: AliceLR <[email protected]>
… null" warning with UBSan
|
The first patch identifies itself as a false positive. In the second, free(NULL) is a NOP so fine (says posix) so whatever the test decides in that case is ok, and what's the problem with postincrementing a null pointer we never use again? Not applying either, they don't fix anything real, just mollify a static analyzer I don't use. |
|
If qsort() is fed an array length of zero, and either reads from or writes to the first element of the array, it's making an access past the end of the array. That would be a bug in qsort. |
|
As an amateur computer historian (https://landley.net/history/mirror etc) I'm curious: what's the last processor that DIDN'T use two's complement for integer math? (Has there been one with a posix build environment?) |
| @@ -141,7 +145,7 @@ static void do_blkid(int fd, char *name) | |||
|
|
|||
| len = fstypes[i].label_len; | |||
| if (!FLAG(U) && len) { | |||
| s = toybuf+fstypes[i].label_off-off; | |||
| s = toybuf+(fstypes[i].label_off-off); | |||
There was a problem hiding this comment.
If this changes the result of the computation, I'm pretty sure that would be a compiler bug?
| if (fstypes[i].magic_len+fstypes[i].magic_offset-off > sizeof(toybuf)) { | ||
| pass++; | ||
| continue; | ||
| } |
There was a problem hiding this comment.
Which entry in fs_types[] has magic/len straddle a 4k boundary? We're supplying the input data here, it's a known set of table entries, the test above this is "we haven't advanced into this block yet", and quite intentionally none of the regions it needs to probe are across a 4k boundary.
Maybe I'm missing something, but... how can this trigger?
This fixes all warnings encountered when running the tests, except for two errors in
toys/lsb/seq.cthat I'm not sure how to fix properly.The first commit is taken from libxmp/libxmp@a2f88d0.